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Abstract. The C++ Standard Template Library is the flagship exam- 
ple for libraries based on the generic programming paradigm. The usage 
of this library is intended to minimize the number of classical C/C++ 
errors, but does not warrant bug-free programs. Furthermore, many new 
kinds of errors may arise from the inaccurate use of the generic program- 
ming paradigm, like dereferencing invalid iterators or misunderstanding 
remove-like algorithms. 

In this paper we present some typical scenarios that may cause run- 
time or portability problems. We emit warnings and errors while these 
risky constructs are used. We also present a general approach to emit 
"customized" warnings. We support the so-called "believe-me marks" 
to disable warnings. We present another typical usage of our technique, 
when classes become deprecated during the software lifecycle. 



1 Introduction 



The C++ Standard Template Library (STL) was developed by generic pro- 
gramming approach [2]. In this way containers are defined as class templates 
and many algorithms can be implemented as function templates. Furthermore, 
algorithms are implemented in a container-independent way, so one can use 
them with different containers [23]. C++ STL is widely-used because it is a 
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very handy, standard C++ library that contains beneficial containers (like 
list, vector, map, etc.) and a large number of algorithms (like sort, find, count, 
etc.) among other utilities [5]. 

The STL was designed to be extensible [14]. We can add new containers that 
can work together with the existing algorithms. On the other hand, we can 
extend the set of algorithms with a new one that can work together with the 
existing containers. Iterators bridge the gap between containers and algorithms 
[4]. The expression problem [26] is solved with this approach. STL also includes 
adaptor types which transform standard elements of the library for a different 
functionality [1]. 

However, the usage of C++ STL does not guarantee bugless or error-free 
code [7]. Contrarily, incorrect application of the library may introduce new 
kinds of problems [22] . 

One of the problems is that the error diagnostics are usually complex, and 
very hard to figure out the root cause of a program error [27, 28]. Violating 
requirement of special preconditions (e.g. sorted ranges) is not tested, but 
results in runtime bugs [20]. A different kind of stickler is that if we have an 
iterator object that pointed to an element in a container, but the element 
is erased or the container's memory allocation has been changed, then the 
iterator becomes invalid [17]. Further reference of using invalid iterators causes 
undefined behaviour [19]. 

Another common mistake is related to removing algorithms. The algorithms 
are container-independent, hence they do not know how to erase elements from 
a container, just relocate them to a specific part of the container, and we need 
to invoke a specific erase member function to remove the elements phisically. 
Since, for example the remove algorithm does not actually remove any element 
from a container [13]. 

Some of the properties are checked at compilation time [8]. For example, 
the code does not compile if one uses sort algorithm with the standard list 
container, because the list's iterators do not offer random accessibility [10]. 
Other properties are checked at runtime [21], like the standard vector container 
offers an at method which tests if the index is valid and it raises an exception 
otherwise [18]. 

Unfortunately, there are still a large number of properties that are tested 
neither at compilation-time nor at run-time. The observance of these proper- 
ties is in the charge of the programmers [6]. On the other hand, type systems 
can provide a high degree of safety at low operational costs. As part of the 
compiler, they discover many semantic errors very efficiently. 

Associative containers (e.g. multiset) use functors exclusively to keep their 
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elements sorted. Algorithms for sorting (e.g. stable_sort) and searching in 
ordered ranges (e.g. lower_bound) are typically used with functors because 
of efficiency. These containers and algorithms need strict weak ordering. Con- 
tainers become inconsistent if used functors do not meet the requirement of 
strict weak ordering [15]. 

Certain containers have member functions with the same names as STL al- 
gorithms. This phenomenon has many different reasons, for instance efficiency, 
safety or avoidance of compilation errors. For example, as mentioned before 
list's iterators cannot be passed to sort algorithm, hence code with this mis- 
take cannot be compiled [24]. To overcome this problem list has a member 
function called sort. In these cases, although the code compiles, the member 
function calls are preferable to the usage of generic algorithms. 

Whereas C+-|- STL is pre-eminent in a sequential realm, it is not aware of 
multicore environment [3]. For example, the Cilk-|— |- language aims at mul- 
ticore programming. This language extends C-|— |- with new keywords and 
one can write programs for multicore architectures easily. Although the lan- 
guage does not contain an efficient multicore library, just the C-|--|- STL only 
which is an efficiency bottleneck in multicore environment. We develop a new 
STL implementation for Cilk-|--|- to cope with the challenges of multicore 
architectures [25]. This new implementation can be safer solution, too. Hence, 
our safety extensions will be included in the new implementation. However, 
the advised techniques presented in this paper concern to the original C-|— |- 
STL, too. 

In this paper we argue for an approach that generates warnings or errors 
when a template container is instantiated with improper parameters. These 
instantiations mean erroneous, unportable code or other weird compilation 
effects. A general technique is presented to express custom warnings at compi- 
lation time. Our technique is able to indicate the usage of deprecated classes. 

This paper is organized as follows. In Section 2 we present an approach 
to generate "customized" warnings at compilation time. After, in Section 3 
we describe the specialized vector container which contains boolean values. 
We show why this container is problematic, and argue for warnings when it 
is in use. We explain the forbidden containers of auto pointers and present 
an approach to disable their usage by template specializations. In Section 5 
the so-called believe-me marks are introduced. Finally, this paper concludes in 
Section 7. 
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2 Generation of warnings 

Compilers cannot emit warnings based on the erroneous usage of the library. 
STLlint is the flagship example for external software that is able to emit 
warnings when the STL is used in an incorrect way [9]. We do not want to 
modify the compilers, so we have to enforce the compiler to indicate these 
kinds of potential problems. However, static_assert as a new keyword is 
introduced in C++Ox to emit compilation errors based on conditions, but no 
similar construct is designed for warnings. 

template <class T> 

inline void warning ( T t ) { } 

struct VECTOR_BOOL_IS_IN_USE { }; 

// ... 

warningC VECTDR_BDDL_IS_IN_USE() ); 

When the warning function is called, a dummy object is passed. This 
dummy object is not used inside the function template, hence this is an unused 
parameter. Compilers emit warning to indicate unused parameters. Compila- 
tion of warning function template results in warning messages, when it is re- 
ferred and instantiated [16]. No warning message is shown if it is not referred. 
In the warning message the template argument is referred. New dummy type 
has to be written for every new kind of warning. 

Different compilers emit this warning in different ways. For instance, Visual 
Studio emits the following message: 

warning C4100: 't' : unreferenced formal parameter 

see reference to function template instantiation 'void 
warning<VECTOR_BOOL_IS_IN_USE> (T) ' 
being compiled 

with 
[ 

T=VECTOR_BODL_IS_IN_USE 

] 
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And g++ emits the following message: 

In instantiation of 'void warning(T) 

[with T = VECTOR_BOOL_IS_IN_USE] ' : 
. . . instantiated from here 
... warning: unused parameter 't' 

Unfortunately, implementation details of warnings may differ, thus there is 
no universal solution to generate custom warnings. 

This approach of warning generation has no runtime overhead inasmuch as 
the compiler optimizes the empty function body. On the other hand — as the 
previous examples show — the message refers to the warning of unused param- 
eter, incidentally the identifier of the template argument type is appeared in 
the message. 

3 The weirdest vector 

In this section we present the basic idea behind the specialized vector<bool> 
container. We present the pros and cons of this weird type. We argue for 
generate warnings at compilation-time if a programmer uses vector<bool> 
because it is the embodiment of the weird container. 

Many programmers think that the vector<bool> is the instantiation of 
STL's vector template, but it is not true. On many platforms sizeof ( int 
) == sizeof ( bool ) because of reverse compatibility. (In the C program- 
ming language int type has been used to represent Boolean values.) Hence, 
the vector<bool> is a template specialized container to develop a more ad- 
vanced, denser implementation for boolean values. This representation is able 
to represent 32 boolean values on 4 bytes. 

The following code sketch represents the connection between vector<bool> 
and vector template: 

template <class T, class Alloc = std::alloc> 

class vector 

{ 

T* p; 

size_t capacity; 
size_t size; 
public : 
vector () 
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{ 

11 ... 

} 

void push_back( const T& t ) 
{ 

// ... 

} 

// ... 

>; 

template <class Alloc> 

class vector<bool, class Alloc> 

{ 

// dense representation of vector bool 
// No bool* member 
public : 

// public interface is similar to the previous one 

void push_back( const bool& t ) 
{ 

// ... 

} 

vector 
{ 

//. . . 

} 

>; 

So, the vector<bool> has a special representation to handle dense boolean 
values. It is designed to be effective when someone stores boolean values. But 
it has weird behaviour compared to the vector template: 

std: :vector<int> a; 
a.push_back( 3 ); 
int* p = &a[0] ; 
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std: : vector<bool> b; 
b.push_back( true ); 
bool* q = &b[0] ; 

The previous code does not compile because of the bool* q = &b[0] ; as- 
signment. However, when the template vector is in use, its counterpart does 
compile. It is a contradiction in terms, because this way the vector<bool> 
cannot meet the requirements of C++ Standard. Hence, it is not advised to 
use. Let us see the background of this compilation issue: 

template <class T, class Alloc = std: :alloc> 

class vector 

{ 

T* p; 
//. . 

public : 

T& operator [] ( int idx ) 
{ 

return p [idx] ; 

} 

const T& operator [] ( int idx ) const 
{ 

return p [idx] ; 

} 

// ... 

}; 

template <class Alloc> 

class vector<bool, class Alloc> 

// dense representation of vector bool 
//No bool* member 
public : 

class bool_ref erence 
{ 

// ... 

>; 
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bool_ref erence operator []( int idx ) 
{ 

// ... 

} 

>; 

Because the vector<bool> does not hold actual bool values it cannot re- 
turn boolfe. Hence, a proxy class is developed which actually simulates bool&. 
However, conversions cannot be defined between pointer to a bool_ref erence 
and a pointer to a bool. This behaviour can be much more appalling, when the 
programmer uses vector as a base class. Arcane error messages are emitted 
when the subtype is instantiated with bool. 

Unfortunately, most of STL references hardly mention that vector<bool> 
is not the instantiation of template, but a completely different class. It would 
be useful if the compiler indicated if the programmer used vector<bool> 
container, even intentionally or inadvertently. 

Now it is not difficult to emit warning with the presented function. Fortu- 
nately, vector<bool> is still a class template because the type of its allocator 
is a template parameter. So, the compilation warning is emitted only when 
this template class is instantiated, hence someone uses it: 

template<class Allocator> 
class vector<bool, Allocator> 
{ 

// ... 

public : 
vector () 
{ 

warningC VECTOR_BOOL_IS_IN_USE() ); 
// ... 

> 

template<class InputIterator> 

vector ( Inputlterator first, Inputlterator last ) 
{ 

warningC VECTOR_BOOL_IS_IN_USE() ); 
// ... 

} 
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vectorC size_t n, const bool& value = boolO ) 
{ 

warning ( VECTOR_BOOL_IS_IM_USE() ); 
// ... 

} 

vector ( const vectorfe rhs) 
{ 

warning ( VECTOR_BOOL_IS_IN_USE() ); 
// ... 

} 

>; 

In Section 2 the emitted warning message can be seen. 

4 Containers of auto pointers 

In this section the containers of auto pointers are detailed. We present their 
motivation and reason why are they problematic. We present a solution to 
forbid the usage of these kinds of containers. 

Usually, auto pointers (std: :auto_ptr objects) make easier to manage ob- 
jects in the heap memory. This class assists in memory management. The auto 
pointers deallocate the pointed memory when they are gone out of scope [23]. 
Hence, they prevent memory leaks: 

void f() 
{ 

std: :auto_ptr<int> p( new int( 5 ) ); 
// no memory leak 

> 

Containers of STL are template classes, so technically they should be in- 
stantiated with auto pointers and store auto pointers that point to the heap: 

std: : vector<std: : auto_ptr<int> > v; 
v.push_back( new int( 7 ) ); 
// ... 



150 



N. Pataki 



The previous code snippet seems to be safe. On the other hand, the C++ 
Standardization Committee forbid the usage of containers of auto pointers 
(COAPs). The motivation behind this idea is that the copy of auto pointers 
is strange: 

std: : auto_ptr<int> p( new int( 3 ) ); 

std: : auto_ptr<int> q = p; 

// At this point p is null pointer 

The copied auto pointer becomes null pointer. Only one auto pointer is able 
to point to any object in the heap. This one is responsible for the deallocation. 

So, if COAPs are not be forbidden, the following code snippet results in a 
very strange behaviour: 

struct Auto_ptr_less 
{ 

bool operator()( const std: :auto_ptr<int>& a, 
const std: : auto_ptr<int>& b ) 

{ 

return *a < *b; 

} 

>; 

std: :vector<std: :auto_ptr<int> > v; 
v.push_back( new int( 7 ) ); 
// ... 

std::sort( v.beginO, v.endO, Auto_ptr_less () ); 

Some of the pointers may become null pointer because of the assignments 
during swapping vector's elements when it is necessary. This is the reason why 
COAPs are forbidden. 

Unfortunately, some of the compilers and STL platforms are still permitting 
the usage of COAPs, some of them are not. This inhibits the writing of portable 
code [13]. 

We argue for an extension to emit compilation error if COAPs are in use. 
We have to create specializations for auto pointers. The trick that is we do 
not write the implementation for the auto pointer specializations. Thus, these 
specializations are declared, but are not defined types. For instance, the vector 
declaration can be the following: 
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template <class T, class Alloc> 

class vector< std: : auto_ptr<T> , Alloc>; 

The instantiation of a COAP results in the hereinafter error message: 

error: aggregate 'std: :vector<std: :auto_ptr<int>, 
std: : allocator<std: : auto_ptr<int> > > v' 
has incomplete type and cannot be defined 

We have to develop these declarations for all standard containers. These 
declarations mean bugless and more portable code. 

5 Believe-me marks 

Generally, warnings should be eliminated. On the other hand, the usage of 
vector<bool> does not necessarily mean a problem. It can be used safely. 
However, we cannot disable the generated warning if it is in use. 

Believe-me marks [12] are used to identify the points in the program text 
where the type system cannot obtain if the used construct is risky. For instance, 
in the hereinafter example, the user of the library asks the type system to 
"believe" that the programmer is conscious of the specialized vector container. 
This way we enforce the user to reason about the parameters of containers. 

First, we create a new type which stands for the believe-me mark: 

struct I_KNOW_VECTOR_BOOL { >; 

After, we extend the vector template container with one new template pa- 
rameter. The new template parameter has default parameter value, so it is 
reverse compatible with the original container. This parameter has not been 
taken advantage of, and has no effect on the implementation: 

template <class T, class Alloc = std::alloc, class Info = int> 
class vector { }; 

Let us consider, that the original implementation of vector<bool> which 
does not generate warning has been removed to a new template class: 

template <class Alloc> 

class VectorBool 

{ 

// original implementation of vector<bool> 

>; 
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The new template parameter has effect on the vector<bool> speciahzation: 
template <class Alloc> 

class vector<bool, I_KNOW_VECTOR_BOOL, AlloO: 
public VectorBool<Alloc> 

{ >; 

template <class Alloc> 

class vector<bool, Alloc, I_KNOW_VECTOR_BOOL> : 
public VectorBool<Alloc> { }; 

template <class Alloc, class Info> 
class vector<bool, Alloc, Info>: 
public VectorBool<Alloc> 

public : 

vectorO: VectorBool<Alloc> () 

{ 

warningC VECTOR_BOOL_IS_IN_USE() ); 

} 

template<class InputIterator> 

vectorC Inputlterator first, Inputlterator last ): 
VectorBool<Alloc> ( first, last ) 

{ 

warningC VECTOR_BOOL_IS_IN_USE() ); 

> 

vectorC size_t n, const boolfe value = bool() ): 
VectorBool<Alloc> ( n, value ) 

{ 

warningC VECTOR_BOOL_IS_IN_USE() ); 

} 

vectorC const vectorfe rhs) : VectorBool<Alloc> C rhs ) 

{ 

warningC VECTOR_BOOL_IS_IN_USEC) ); 

> 

}; 
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In this case no compilation warning is emitted if the last added template 
parameter is I_KNOW_VECTDR_BDDL, otherwise the mentioned warning can be 
seen during compilation. 

6 Deprecated classes 

In section 3 we generated warnings when a template-specialized class was used. 
A similar idea can be mentioned. It would be useful to generate warnings when 
the usage of classes becomes unsupported. 

A common idea during a software lifecycle is, that some of the classes are 
not deleted from the project, but their usage is not advised. These classes are 
called deprecated. Deprecated annotation can be added to classes in Java. In- 
stantiation of deprecated classes results in compilation warnings [11]. However, 
no similar technique is used in C+-|-. 

First, we create some utility classes for warning generation: 

struct DeprecatedClass { }; 

template <class DEPRECATED> 

struct Deprecated 

{ 

DeprecatedO 
{ 

warningC DeprecatedClass () ); 

} 

>; 

The role of the template parameter in Deprecated struct is to pass the 
identifier of deprecated class to the emitted warning. 

Now, let us consider that the following class becomes deprecated during 
software lifecycle: 

class Foo 
{ 

// ... 

public : 

Foo( int a, int b) 
{ 

// ... 

} 

>; 
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The user has to add one more base class to the deprecated class. This does 
not mean limitation because the C++ programming language supports mul- 
tiple inheritance. For example: 

class Foo: public Deprecated<Foo> 
{ 

// very same . . . 

>; 

The following warning is received from the compiler: 

In instantiation of 'void warning (T) 
[with T = DeprecatedClass] ' : 

instantiated from 
'Deprecated<DEPRECATED>: :Deprecated() 
[with DEPRECATED = Foo] ' 
instantiated from here 
... warning: unused parameter 't' 

However, this message is received irrespectively of its usage. If the usage 
is important, the deprecated class or a called method or constructor must be 
a template. This transformation cannot be executed automatically with the 
respect of client code. Our future work is to overcome this situation. 

We do not advise to make believe-me marks for the deprecated classes inas- 
much as always exists a better approach to use. 

7 Conclusions 

C++ STL is the most widely-used library based on the generic programming 
paradigm. It is efficient and convenient, but the incorrect usage of the library 
results in weird or undefined behaviour. 

In this paper we argue for some extensions to make the STL itself safer. Not 
supported or not advised instantiations result in compilation warnings and 
errors to prevent unportable or defective code. 

We present an effective approach to generate custom warnings. Believe-me 
marks are also written to disable warning messages. With our technique classes 
can be marked deprecated, too. 
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